In the past, when a business wanted to schedule a shipment of goods from one of its suppliers, the business would have to contact the supplier over the phone or by mail to request that a shipment be made within certain preferred blocks of time on certain specified days. For example, the business might request that a shipment be made on Monday, July 19, between 1:00 pm and 5:00 pm, or on Tuesday, July 20, between 9:00 am and 12:00 pm. The supplier would then enter this order into a mainframe-based routing-and-scheduling program for processing. Later, the various orders would be processed along with other orders in a batch to determine when the various orders would actually be delivered. The business would then be informed as to whether the delivery would be made at one of the specified preferred times, or at some other time. Thus, there was a delay between the time that the business placed the order and the time that a delivery time for the order was confirmed.
Computer systems have now been developed that allow customers to schedule deliveries in real-time over the Internet. These systems generally allow users to schedule deliveries, one at a time, by selecting a time window in which the delivery is to be made from one or more available time windows.
One example of such a system is Webvan's Internet-based scheduling system for home grocery delivery. When using this system, a customer logs on to Webvan's website and then selects a date on which the customer wishes to have groceries delivered to their home. The system then identifies any time windows that are available for the customer's requested date and immediately displays a list of available and unavailable time windows on the customer's display screen. After the customer selects an available time window, the system instantly schedules a delivery to be made within the selected time window. If desired, the customer may schedule additional deliveries by repeating this process.
More specifically, when using the Webvan system, a user might request, for example, that a particular delivery be made on Sep. 28, 2001. In response, the system may indicate, for example, that it only has the capacity to make the requested delivery within the following time windows on September 28: (1) 9:00 am–10:00 am; (2) 11:00 am–12:00 pm; and (3) 2:00 pm–3:00 pm. In one example, the user might request that the delivery be made within the 9:00 am–10:00 am time window. In response, the system will instantly confirm that the particular delivery will be made on September 28 between 9:00 am and 10:00 am.
One disadvantage of current on-line, real-time delivery scheduling systems is that such systems require a customer to schedule each delivery individually. As a result, while these systems work well for customers (such as on-line bookstore customers) who place orders that vary in content and delivery time, these systems are not particularly convenient for users who wish to have the same delivery made on a periodic basis. For example, if a customer wishes to have the same set of items delivered to their home every other Thursday, the customer must re-schedule the delivery once every two weeks. This is undesirable because it requires the customer to spend an often significant amount of time regularly re-scheduling the order. In addition, real-time prior art systems do not allow the customer to reserve a series of delivery times in advance. Thus, because the customer has to reserve each delivery time within a series of deliveries individually, the customer must compete with other customers for each individual delivery time within the series. As a result, no customer can be sure that they will be able to schedule each delivery within a series of deliveries according to a set, periodic schedule.
In addition to allowing users to schedule deliveries, at least one prior art delivery scheduling program allows users to request that items be picked up from a business on a specified day. For example, U.S. Pat. No. 5,616,899 to Recigno teaches a scheduling system that allows a user to specify dates on which orders for dental appliances are to be picked up from various dental offices. However, like the early delivery scheduling systems discussed above, the Recigno system is not capable of functioning in a real time environment. Rather, to schedule a pickup, users must call a central dispatching center and request that a particular pickup be made at a preferred time on a preferred day. The user's request is then presumably entered into an offline system and the requested pickup is scheduled at a later time, presumably by hand or by using a standard off-line scheduling system. Although customers' delivery preferences are considered during scheduling, these preferences are presumably often overridden by other considerations, such as a deliverer's ability to make a pickup at a requested time.
Recigno teaches allowing a user to enter a standing request that a repeating series of pickups be made regularly on certain specified days. Thus, for example, a user may request that items be picked up from the user's offices on a weekly basis. When a user wishes to request that a pickup be made according to such a repeating schedule, the user manually enters the request into a “Pickup/Delivery Preferences” Box on a “Schedule Pickup/Delivery” input screen 194 such as the screen shown in FIG. 17A of Recigno. While this functionality is not described in detail in the application, it is presumed that such requests are processed offline by hand or by a standard offline routing and scheduling system. Accordingly, it is understood that users' requests that a pickup be made on a recurring basis are often accepted, but not satisfied, by the Recigno system.
Accordingly, one significant disadvantage of the Recigno system is that it provides no immediate feedback to users as to whether the system will be able to make any particular pickup within a requested series of pickups. Thus, for example, the system may allow a user to request that a pickup be made every Wednesday, even if no delivery trucks will be available to make a pickup for the next seven Wednesdays. In such a situation, even if the user properly requested that the pickup be made every Wednesday, the system would actually schedule the first seven pickups within the series of requested pickups to be made on days other than Wednesday. While such a system may be acceptable for scheduling pickups from commercial establishments that generally have employees available to assist with pickups during regular business hours (and that can, therefore, tolerate unpredictable variances in pickup schedules), such a system would not be useful for scheduling time-sensitive pickups from less tolerant customers, such as residential customers.
Thus, in light of the above, there is a need in the art for an improved delivery scheduling system that allows a user to schedule, in real time, two or more delivery vehicle visits (such as pickups or deliveries) in response to a single request. Preferably, such a system would allow the user to at least tentatively confirm the scheduled delivery vehicle visits upon scheduling the delivery vehicle visits, and would inform the user in advance if a particular delivery vehicle visit must be rescheduled.